Как все присутствующие здесь знают, компания VMware недавно выпустила новую версию решения для виртуализации серверов VMware vSphere 6, в которой присутствует огромное количество новых функций.

Но стоит ли делать апгрейд на новую версию прямо сейчас? Давайте попробуем рассмотреть все за и против.

Знаете еще причины, по которым не стоит обновляться на vSphere 6? Пишите в каменты!

P.S. Опытные люди говорят, что обновляться до Update 1 нельзя.

Как вы знаете, автор этого сайта придерживается правила "лучше переставлять, чем обновлять" (когда речь идет о мажорных версиях продукта - см., например, вот тут и тут).

В VMware vSphere 5.0 компания VMware обновила свою кластерную файловую систему до версии VMFS 5. При этом в vSphere 5.x тома VMFS-3 поддерживаются, а также доступен апгрейд с третьей версии на пятую (напомним, что в пятой версии появилась поддержка дисков в 64 ТБ). Более подробная информация об апгрейде VMFS приведена в документе "VMware vSphere VMFS-5 Upgrade Considerations".

Так вот, апгрейженный том VMFS-5 имеет ограниченную функциональность в отличие от созданного заново тома, а именно:

• Апгрейженный том продолжает использовать исходный размер блока (в новой версии VMFS 5.x размер блока унифицирован - 1 МБ). Это иногда может привести к чрезмерному потреблению места на диске (если много мелких файлов), но что самое неприятное - к падению производительности Storage vMotion.
• Апгрейженный том не имеет таких возможностей как Sub-Block Size, увеличенное число файлов на хранилище и разметка GPT.
• Обновленный том VMFS-5 продолжает иметь раздел, начинающийся с сектора 128, это может вызвать некоторые проблемы с выравниванием блоков. Новый раздел VMFS 5 начинается с сектора 2048.

Таким образом, получается, что лучше создать новый том VMFS-5, чем обновлять существующие тома VMFS-3. Но это все было давно, ну а вдруг у вас остались такие вот обновленные VMFS, из-за которых у вас иногда что-то работает не так?

Проверить, какой у вас том, можно в vSphere Client или vSphere Web Client. Смотрим размер блока:

Если он не 1 МБ - то это точно апгрейженный том, и его неплохо бы пересоздать. А вот если 1 МБ, то вовсе не факт, что это новый том (как раньше, так и сейчас был такой размер блока). В этом случае вам поможет вот этот скрипт, который выводит список всех томов VMFS и показывает, новый это том или апгрейженный.

Запустить этот скрипт можно таким образом:

1. Загружаем его и переименовываем его в check_vmfs.sh, убрав расширение .doc.

2. Копируем скрипт на виртуальный модуль vMA. Можно также запускать скрипт локально на сервере ESXi - для этого его туда надо загрузить через Veeam FastSCP или WinSCP.

3. Включаем демон SSH на хостах ESXi, где вы будете выполнять скрипт. (в vSphere Client нужно зайти в Configuration \ Software \ Security profile \ Services \ SSH).

4. Удаленно выполнить скрипт на серверах через SSH можно с помощью команды:

ssh root@<ESXi IP> 'ash -s' < ./check_vmfs.sh

Далее попросят пароль и будет выведен результат работы скрипта.

Здесь нужно смотреть на значение Sub Blocks, если Sub Blocks = 3968, то это апгрейженный VMFS-5, и его неплохо бы пересоздать. У нормального VMFS-5 значение Sub Blocks равно 32000.

Такое вот работающее правило "лучше переставлять, чем обновлять". Любители PowerShell могут также посмотреть вот эту статью.

Многие администраторы в курсе, что обновление до Windows 8.1, которое вышло в конце прошлого года, было рекомендовано к установке всем пользователям Windows 8. Однако оно не было обязательным. Теперь же с выходом Windows 8.1 Update 1 сделать это фактически заставят.

Поэтому, приведем здесь пару важных аспектов по обновлению виртуальных ПК.

Во-первых, перед обновлением до Windows 8.1 надо удалить агента VMware View Agent, далее обновить гостевую ОС, а уже после этого поставить агента заново. Но лучше всего - развернуть для пользователя уже новую операционку с Windows 8.1. Это все в рамках стратегии, что всегда лучше ставить заново, чем обновлять (если это, конечно, не очень запарно).

Во-вторых, VMware Horizon View 5.3.1 не поддерживает функции VMware View Persona Management для Windows 8.1. Поэтому когда будете устанавливать VMware View Agent и увидите там отмеченную галку, не обольщайтесь - эти функции работать не будут (не установятся).

Об остальных проблемках с Windows 8.1 и VMware View можно почитать вот тут. Ничего фатального на самом деле.

Как знают все те, кто интересуется решением для создания отказоустойчивых хранилищ StarWind iSCSI SAN, совсем недавно вышла обновленная версия StarWind V8 RC, которая пришла на смену StarWind V8 Beta 3. Многие администраторы заметили, что после обновления на новую версию невозможно снова примонтировать виртуальные тома в консоли StatWind:

В данном случае ничего сделать не получится - поскольку в версии RC поменялся формат файловой системы LSFS, то апгрейдить такие устройства и снова подключить их не удастся. Придется создавать новые.

Те из вас, кто уже установил версию StarWind V8 RC, могут заново скачать установщик StarWind V8 Beta 3, где можно снова подключить старые устройства и скопировать с них необходимые данные. Старый установщик Beta 3 доступен по этой ссылке: http://starwindsoftware.com/tmplink/StarWindBeta-20140206.exe.

Общая процедура обновления на новую версию StarWind V8 RC приведена вот в этом документе.

Продолжаем рассказывать о решении StarWind iSCSI SAN, предназначенном для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин (есть версия как для VMware, так и для Hyper-V).

Многих пользователей StarWind волнует вопрос о миграции хранилищ с Windows 2008 на Windows 2012 R2, которую они планируют сделать одновременно с обновлением на StarWind V8.

Вот простой алгоритм, как правильно обновить ОС узлов StarWind iSCSI SAN и (опционально) обновить сам продукт на новую версию:

1. Используя Replication manager, необходимо отсоединить все узлы-партнеры от устройств первого узла (StarWind1).
2. На этом узле (StarWind1) нужно установить новую ОС.
3. Далее нужно установить StarWind V6 на этом узле. 
4. Ко всем устройствам на StarWind1 нужно добавить их HA-партнеров через Replication manager и запустить синхронизацию.
5. Дождаться окончания синхронизации и соединиться с новыми таргетами.
6. Удалить всех HA-партнеров от второго (StarWind2) через Replication manager.
7. Установить новую ОС на StarWind2.
8. Установить StarWind V6 на StarWind2. 
9. Добавить партнеров ко всем HA-устройствам на узле StarWind2 через Replication manager.
10. Дождаться окончания синхронизации и соединиться с новыми таргетами.
11. Обновить StarWind V6 на StarWind V8, следуя вот этой процедуре.

Более подробно этому посвящена вот эта ветка форума StarWind.

Для всех пользователей StarWind!

Уже подходит к концу программа "Customer Loyalty Upgrade Program", которая позволяет клиентам StarWind iSCSI SAN (для VMware vSphere) или Native SAN (для Microsoft Hyper-V) произвести обновления своих продуктов на более старшие версии со скидкой до 35%. Предложение действует только до конца июня, поэтому поторопитесь с заказом.

Напомним, что StarWind - это средство номер 1 для создания отказоустойчивых хранилищ iSCSI для виртуальных машин.

Вот условия обновления для тех, кто уже использует продукты StarWind:

• 15% скидка - для обновления на издание на одну ступень вверх (например, с 1TB до 2TB или с 4TB до 8TB).
• 25% скидка – для обновления на издание на две ступени вверх (например, с 1TB до 4TB).
• 35% discount – для обновления на издание на три или более ступени вверх (например, с 1TB до 16TB).

Торопитесь и заказывайте обновление StarWind со скидкой.

На страницах vSphere Blog обнаружилась интересная статья Вильяма Лама про патчи, накатываемые на гипервизор VMware ESXi. Приведем здесь основные выдержки, которые могут оказаться полезными при обслуживании виртуальной инфраструктуры VMware vSphere.

Итак, для начала приведем структуру разделов на диске установленной копии ESXi:

Основное отличие от традиционной ОС в VMware ESXi - это то, что все файлы, необходимые гипервизору, хранятся в разделе фиксированного объема (Primary Boot Bank - 250 МБ). Альтернативный Boot Bank такого же размера необходим на случай отката к предыдущей версии ESXi, вне зависимости от того был ли произведен Update (накатывание патчей) или Upgrade (накатывание новой версии ESXi).

Если мы произведем апгрейд ESXi 5.0 на версию 5.1, то структура банков поменяется следующим образом:

Хотя это на самом деле даже и не так - ESXi 5.0 останется в прежнем банке, а загрузчик (Boot Loader) будет указывать уже на альтернативный банк, где разместится ESXi 5.1.

Когда происходит накатывание патча на ESXi - меняется весь банк (основной или альтернативный), поэтому патчи так много весят (по сути обновляется весь основной дистрибутив):

Но в этом есть и преимущество - размер раздела для банка фиксирован и установка ESXi не разрастается со временем при установке новых апдейтов и апгрейдах. Кстати, обратите внимание, что под патчем написано его влияние на систему после установки.

Следующий момент: являются ли патчи кумулятивными, то есть содержат ли они все предыдущие обновления ESXi? Да, все патчи содержат в себе предыдущие, поэтому нет необходимости накатывать их последовательно. Скачать патчи VMware ESXi можно с Patch Portal.

Далее, мы видим, что у патча есть список Bulletin List с суффиксом BG (Bug Fix). Есть также и SG-бюллетени обновлений по безопасности (Security). Оба этих типа бюллетеней могут обновлять как основной банк (base), так и пакеты VMware Tools (драйверы и прочее). Кроме того, в бюллетенях содержатся обновления драйверов устройств для самого сервера ESXi.

SG-бюллетень содержит только обновления подсистемы безопасности, а BG-бюллетени могут содержать новый функционал, исправления ошибок и, опять-таки, обновления, касающиеся безопасности.

Наконец, каждый бюллетень состоит из VIB-пакетов, о структуре которых Вильям хорошо рассказал вот тут. Список установленных VIB-пакетов на хосте ESXi можно узнать командой:

# esxcli software vib list

Будет выведено что-то вроде:

Name              Version                     Vendor Acceptance Level Install Date
----------------- --------------------------- ------ ---------------- ------------
ata-pata-amd      0.3.10-3vmw.500.0.0.469512  VMware VMwareCertified  2012-05-04
ata-pata-atiixp   0.4.6-3vmw.500.0.0.469512   VMware VMwareCertified  2012-05-04
ata-pata-cmd64x   0.2.5-3vmw.500.0.0.469512   VMware VMwareCertified  2012-05-04
ata-pata-hpt3x2n  0.3.4-3vmw.500.0.0.469512   VMware VMwareCertified  2012-05-04

О том, как накатывать патчи на ESXi из консоли мы уже писали вот тут, также об этом рассказано в KB 2008939.

Как многие из вас знают, в VMware vSphere 5.1 была введена возможность обновления пакета VMware Tools "без перезагрузки" гостевой ОС. Многие пользователи были удивлены - как же так, после обновления драйверов не нужно перезагружать сервер? На самом деле это небольшой маркетинговый обман - перезагружать ОС в некоторых случаях, все-таки, придется - чудес не бывает.

Просто исторически (до vSphere 5.1) обновление VMware Tools в любом из компонентов этого пакета требовало перезагрузки. При этом для Windows-систем ее можно было отложить используя опции установщика, например, такие (или так):

setup.exe /S /v"/qn REBOOT=R"

или

setup.exe /S /v"/qn REBOOTPROMPT=S"

Для ОС Unix/Linux драйверы и модули ядра отправлялись на стейджинг и активировались в системе после перезагрузки сервера.

Теперь же, в vSphere 5.1 обновление не всех компонентов VMware Tools требует перезагрузки, однако это применимо только к ОС Windows, для Linux все осталось по-прежнему. Перезагрузка требуется при обновлении следующих компонентов, входящих в состав пакета VMware Tools:

• Драйвер видеоадаптера VMware SVGA II. Он используется для ОС младше Windows Vista, однако может использоваться в некоторых случаях и для других ОС. Если в системе установлен драйвер VMware SVGA 3D, то его обновление, скорее всего, не потребует перезагрузки. Однако в KB 2015163 указано, что перезагрузка произойти, все-таки, может.
• Драйвер VMware Pointing Device Driver (PS/2). Этот драйвер используется по умолчанию для всех версий Windows, но обновляется крайне редко. В VMware vSphere 5.1 появился VMware USB Pointing Device driver, который не требует перезагрузки. Если это критично - можно использовать его.
• Драйверы VMware VMSCSI Controller и VMware PVSCSI Controller Driver. Обновление этих драйверов, скорее всего, потребует перезагрузки, но только в случае, если один из этих драйверов используется для системного диска (с папкой C:\Windows), либо для устройства, файловая система которого используется на момент установки. В других случаях (например, у вас нет дисков на контроллере PVSCSI) - перезагрузка не требуется.
• Опциональные компоненты. К ним относятся HGFS (функции shared folders) и ThinPrint, которые могут потребовать перезагрузки.

Какие особенности есть у процесса обновления VMware Tools без перезагрузки в VMware vSphere:

• Работает это для Windows Vista и выше.
• Работает только для ОС Windows.
• Для виртуальной машины требуется Virtual Hardware 9 или более поздней версии.

Также стоит прочитать статью о том, следует ли обновлять VMware Tools при апгрейде хостов VMware vSphere.

На сайте проекта VMware Labs (напомним про наш тэг проекта) не так давно появилась утилита VMware vCenter 5.1 Pre-Install Check Script. Не будучи полностью поддерживаемым и оттестированным продуктом, эта утилита будет полезна администраторам, которым необходимо установить или обновить сервер управления vCenter до версии 5.1. Этот скрипт PowerShell / PowerCLI позволяет проверить, что все необходимые требования для установки vCenter 5.1 выполнены:

Скрипт осуществляет следующие виды проверок:

• Проверка ОС сервера
• Проверка домена Active Directory
• Проверка леса Active Directory
• Проверка синхронизации времени
• Проверка системы разрешения имен (DNS)
• Проверка доступности необходимых портов
• Тест контроллера домена
• Проверка аутентификации vCenter Server

Скрипт запускается просто, без параметров:

PS C:\>cd Scripts

PS C:\Scripts>.\PreCheckv2.ps1

Пример работы VMware vCenter 5.1 Pre-Install Check Script показан на видео ниже:

Более подробно об этом скрипте можно узнать на этой странице.

На видео ниже рассказано о процессе обновления продукта для создания отказоустойчивых хранилищ StarWind iSCSI SAN с версии 5.8 на версию 6.0:

Мы уже много писали о продукте номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN 6.0, в том числе про экономическую эффективность решения и его новые возможности. Также публиковали и запись вебинара о новых возможностях шестой версии.

Теперь же мы хотим пригласить вас на вебинар "Upgrade from StarWind v.5.8 to StarWind v.6.0", посвященный тому как правильно и без потерь обновиться на шестую версию.

Вебинар пройдет 8 ноября в 23 часа по московскому времени. Самое то, чтобы спокойно посмотреть вечерком.

В рамках вебинара будут рассмотрены следующие вопросы:

• Почему нужно делать апгрейд на StarWind 6.0, если текущая версия работает хорошо
• Нужно ли что-нибудь перенастраивать для апгрейда?
• Как быть уверенным в том, что данные не будут потеряны
• Как долго будет происходить синхронизация после апгрейда узла

Регистрация на вебинар.

Перед пользователями бесплатного продукта vSphere Hypervisor (ESXi Free), которые используют версию ESXi 5.0, после выхода VMware vSphere 5.1 встала проблема обновления продукта на версию 5.1.

Пошаговая инструкция, как обновить хосты ESXi 5.0 на ESXi 5.1:

1. Скачиваем ESXi 5.1 Offline Bundle с сайта VMware (файл VMware-ESXi-5.1.0-799733-depot.zip). Если вы не авторизованы для загрузки файла, то можно использовать ссылку на загрузку пробной версии vSphere 5.1.

2. Загружаем этот бандл на одно из хранилищ VMware ESXi.

3. Соединяемся с хостом по SSH и выполняем следующую команду:

esxcli software profile install -d <путь к бандлу 799733.zip> -p ESXi-5.1.0-799733-standard

либо эту:

esxcli software profile update -d <путь к бандлу 799733.zip> -p ESXi-5.1.0-799733-standard

Отличия команд в следующем:

• install - полностью переустановит все пакеты ESXi 5.0 на 5.1 - аналог чистой установки.
• update - обновит пакеты, относящиеся к ESXi 5.0 на 5.1, но не тронет сторонние пакеты - например, драйверы устройств, которые вы устанавливали самостоятельно.

4. Перезагрузите сервер VMware ESXi.

При включении виртуальной машины, после обновления на ESXi 5.1, вы можете получить сообщение:

This Virtual Machine might have been moved or copied

Это из-за того, что у хоста ESXi 5.1 появился новый UUI. Выбирайте "I moved it". Подробнее тут.

После того, как вы поняли, что хост ESXi 5.1 работает стабильно - время обновить Virtual Hardware и VMware Tools. Если вы не знаете, как это делать, то загляните в KB 1010675.

Если же ваш хост VMware ESXi 5.0 имеет доступ в интернет, то можно обновить сервер на ESXi 5.1 напрямую из репозитория VMware. Для этого:

1. Открываем доступ в сетевом экране ESXi для http-клиента:

esxcli network firewall ruleset set -e true -r httpClient

2. Делаем чистую установку (install) напрямую из хранилища:

esxcli software profile install -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-5.1.0-799733-standard

или update:

esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-5.1.0-799733-standard

Если вы еще не проводили миграцию на VMware vSphere 5, то нужно обратить внимание на утилиту VMware vCenter Database Pre-Upgrade Checker, которая позволит вам проверить возможность миграции базы данных существующего vCenter 4.0 или 4.1 на новую версию vCenter 5.0. В больших окружениях, где неизвестно, что и как изменялось в БД vCenter данная утилита может оказаться очень актуальной.

Что проверяет VMware vCenter Database Pre-Upgrade Checker:

• Различные схемы в БД vCenter
• Проверка корректности пользователей и ролей (достаточность привилегий конкретного пользователя на апгрейд)
• Проверка структуры таблиц (без проверки данных)
• Проверка корректно выставленного режима совместимости (SQL compatibility mode) для Microsoft SQL Server при апгрейде

Перед использованием VMware vCenter Database Pre-Upgrade Checker необходимо сделать следующие вещи:

• Pre-Upgrade использует 32-битные dll-ки для разрешения ODBC DSN-ов, поэтому необходимо установить 32-битный пакет JRE/JDK 1.6 update 19 или более поздней версии.
• Добавить в переменную PATH на сервере vCenter путь к директории bin для JDK. Для этого идем в Control Panel > System > Advanced system settings > на вкладку Advanced > Environment variables > выбрать System Variables (for all users) или User Variables (for this login user only) > выбрать переменную PATH, после чего нажать Edit (для изменения существующей переменной) и добавляем перед остальными путями строчку (разделитель с уже существующими путями - точка с запятой):
  
c:\Program Files\java\jdk1.6.0\bin
   
• Убедиться, что для СУБД MS SQL включен протокол TCP/IP. Для этого идем в SQL Configuration Manager -> SQL Server Network Configuration и выбираем "Protocols" для экземпляра БД vCenter.

Теперь запускаем VMware vCenter Database Pre-Upgrade Checker:

1. Скачиваем утилиту с сайта: https://download3.vmware.com/software/dbchecker_10/DBPreUpgradeChecker.zip.

2. Запускаем .bat-скрипт "DBPreUpgradeChecker.bat":

3. Выбираем способ соединения через ODBC или ввод логина-пароля. В поле RDBMS выбираем БД MS SQL или Oracle, после чего вбиваем параметры БД.

4. Выбираем, где хранить xml-файл конфигурации (signature profile configuration file).

5. Когда введенной информации для БД будет достаточно - станет активной кнопка "Run!". Нажимаем ее и смотрим информационные сообщения утилиты.

Видов результатов бывает много, и приведены они в KB 2004286.

Update: источник логического строения заметки: http://www.vladan.fr/vcenter-pre-upgrade-check-tool-1-0-released/

Если вы обновляли хосты VMware vSphere 4.1 на vSphere 5.0, то у вас может возникнуть ошибка "Operation timed out" при переходе хост-сервера ESXi 5.0 в состояние "Election", т.е. выбора мастера операций (см. нашу статью о VMware HA в vSphere 5.0).

Когда инициируется запрос "start" для FDM, агент не запускается и HA пытается переустановить его, что также заканчивается неудачно, поскольку он имеет правильную версию и вроде как установлен нормально. Однако HA в этом случае не работает. Детали вы найдете вот в этой ветке на VMTN.

Это очередное доказательство той мысли, которую мы доносим с выходом каждой новой мажорной версии vSphere - никогда не делайте апгрейд на новую версию, а всегда переустанавливайте хост-серверы ESXi (потому что баги выползают буквально с каждым релизом).

Для решения проблемы нужно сделать следующее:

1. Перевести хост в режим обслуживания (Maintenance Mode) и убрать с него все ВМ.
2. Скопировать файл /opt/vmware/uninstallers/VMware-fdm-uninstall.sh куда-нибудь во временную папку (например, /tmp)
3. Из приведенной выше папки (/tmp) запустить скрипт ./VMware-fdm-uninstall.sh
4. Будет небольшая задержка на выполнение скрипта.
5. Вывести хост из Mainenance Mode и на панели "Recent Tasks" убедиться, что vCenter начал переустановку агента.

Это, по-идее, должно помочь. Ну и не забывайте, что все логи VMware HA на хосте (а именно, FDM-агента) хранятся в файле var/log/fdm.log.

Очень полезной может оказаться не только указанная ветка Community, но и статья KB 2004429.

Update: проблема оказывается серьезнее - она касается также ситуации, когда вы просто накатили патчи на ESXi 5.0 (см. комментарии).

Интересное (но неофициальное) исследование на тему миграции на новую версию платформы VMware vSphere 5 опубликовано на блоге virtualgeek. Было опрошено 1935 респондентов. Напомним, что VMware vSphere 5 вышла в августе этого года.

Самый занимательный график - это ответы на вопрос "Какую версию VMware vSphere вы сейчас используете?" (допускалось более одного варианта ответа):

59,2% для vSphere 5 - это очень и очень большой показатель, учитывая выход продукта 4 месяца назад.

Полезен также график ответов на вопрос "Используете ли вы другие технологии виртуализации":

Ну Hyper-V понятно, но, фигасе, XenServer жжет. Неожиданно.

Далее вопрос о проценте виртуализованных серверов (но надо учитывать специфику исследования - отвечали люди, которые крутятся в сфере виртуализации). График в лучших традициях Чурова, но автор говорит, что результат где-то 86%.

Далее - тоже интереснейшая тема. Системы хранения каких вендоров используют под виртуализацию:

EMC на высоте - молодцы. Но, по-моему, автор из EMC, поэтому тоже надо на это делать скидку.

Ну и теперь - ответьте на вопросы для нашего небольшого исследования:

Опрос VM Guru - 4 вопроса!

Результаты будут вывешены как только наберется репрезентативная выборка. Спасибо!

Как вы знаете, в VMware vSphere 5 версия файловой системы VMFS была продвинута до 5. Это дает множество преимуществ по сравнению с VMFS 3, в частности, возможность создания хранилищ виртуальных машин (Datastore) размером до 64 ТБ без необходимости создания экстентов.

Это стало возможным благодаря использованию GPT-разделов (GUID Partition Table) вместо MBR-разделов (Master Boot Record). При этом, существует ошибочное мнение, что для томов VMFS 3, обновляемых на VMFS 5, ограничения старой версии в 2 ТБ на файловую систему Datastore остаются. Это не так - VMFS 5.0 при обновлении на нее с третьей версии действительно сохраняет формат MBR, однако после расширения тома более 2 ТБ происходит автоматическая конвертация MBR в GPT-диск.

То есть, происходит это так. У нас есть том VMFS 3, мы нажимаем ссылку "Upgrade to VMFS 5":

После прохождения мастера обновления, видим что тип тома - VMFS 5:

Однако здесь также видно, что том VMFS (теперь уже 5-й версии) остался размеров в 2 ТБ, несмотря на то, что LUN может быть более 2 ТБ. Кроме того, том остался MBR-форматированным, а размеры блоков VMFS 3 для него остались неизменными (см. KB 1003565). Надо отметить, что вновь создаваемые тома VMFS 5 всегда создаются с унифицированным размером блока - 1 МБ.

Чтобы расширить том VMFS, вызываем мастер "Increase Datastore Capacity":

Расширяем том, например до 3 ТБ:

Обратите внимание, что VMFS 5 не дает нам увеличения размера файла (vmdk) по сравнению с предыдущей версией - максимум по прежнему 2 ТБ, просто теперь том может быть размером до 64 ТБ без экстентов.

Запустим fdisk, посмотрим свойства расширенного тома и увидим, что он теперь GPT-том:

Далее операции с таким диском производятся с помощью утилиты partedUtil, но это уже другая история.

На сайте проекта VMware Labs, где публикуются результаты внутренних разработок VMware (т.е. утилиты, которые факультативно разрабатываются сотрудниками компании) появилась новая утилита ESX System Analyzer.

ESX System Analyzer - это утилита, поставляемая в виде готового виртуального модуля (Virtual Appliance), которая позволяет пользователям спланировать миграцию хост-серверов ESX на платформу ESXi. Она анализирует серверы ESX в виртуальной инфраструктуре и собирает для каждого хоста информацию, которую необходимо учитывать в процессе миграции:

• Аппаратную совместимость серверов с ESXi
• Виртуальные машины, зарегистрированные на хосте ESX, а также ВМ, которые находятся на локальных дисках
• Отличия настроек компонента Service Console от стандартных:
  • RPM-пакеты, которые были добавлены или удалены
  • Файлы в сервисной консоли, которые добавляли пользователи
  • Добавленные пользователи и задачи cron

• Версии VMware Tools и Virtual Hardware для всех виртуальных машин
• Версии файловых систем для томов VMFS

• Переместить ВМ с локальных дисков на общие хранилища
• Понять, как можно заменить агентов в сервисной консоли на их безагентные альтернативы или CIM-агенты
• Заменить задачи cron удаленными скриптами PowerCLI или vCLI

Системные требования к ВМ, содержащей ESX System Analyzer (работа с утилитой производится через веб-интерфейс):

• 20GB virtual disk
• 512MB virtual memory
• 1 vCPU
• vCenter Server 2.5, 4.0, 4.1, 5.0
• ESX Hosts 3.5, 4.0, 4.1
• Административный доступ к vCenter Server
• Root password для анализируемых ESX
• Включенный доступ Root по SSH на всех хостах

Скачать ESX System Analyzer можно по этой ссылке. Инструкция по работе с продуктом - тут.

На мероприятии UK VMware User Group Julian Wood представил интересную презентацию, которая суммирует необходимые дествия и процедуры по миграции с платформы VMware vSphere 4 на vSphere 5, включая хост-серверы ESX / ESXi, vCenter (включая его компоненты), виртуальные машины, VMware Tools и тома VMFS.

Один из лучших материалов, обобщающих информацию на тему миграции на vSphere 5.

Пост в рамках заказанной вами рубрики "Что почитать?". Компания VMware на прошедшей неделе выпустила несколько очень нужных, полезных, а главное интересных для чтения документов. Вот они:

1. VMware vSphere 5.0 Upgrade Best Practices.

Документ описывает лучшие практики по переходу на VMware vSphere 5 с предыдущих версий, включая хост-серверы VMware ESXi, сервер vCenter и его базу данных. См. также нашу серию статей о миграции на vSphere 5.

2. VMware ESXi 5.0 Operations Guide.

В документе описаны основные рабочие процессы по управлению сервером виртуализации VMware ESXi 5, включая интерфейс vCLI, PowerCLI, управление через SSH и многое другое. Документ будет полезен многим, особенно пользователям бесплатного ESXi и изданий Essentials.

3. VMware View 5 with PCoIP Network Optimization Guide.

Самый нужный документ для тех, кто планирует внедрение инфраструктуры виртуальных ПК VMware View 5 в условиях высокой нагрузки на канал. В документе рассматривается тонкая настройка протокола PCoIP с помощью групповых политик, все с картинками - просто и понятно. Например, выставление maximum frame rate в 15 и maximum initial image quality в диапазоне 70-80 уменьшает требование к каналу в 2-4 раза при сохранении приличного качества картинки при просмотре видео.

4. VMware View 5 Performance and Best Practices.

Этот документ уже сфокусирован на производительности решения VMware View 5 в целом. Приведены примеры тестирования решения для различных настроек протокола PCoIP и других компонентов.

Продолжение обзора новой документации не заставит себя долго ждать.

Компания VMware, чтобы морально и материально подготовить пользователей VMware vSphere 4.x и VMware VI 3 к переходу на новую версию VMware vSphere 5, выпустила специальную утилиту vSphere Licensing Advisor.

Как вы знаете, издания VMware vSphere 5 будут лицензироваться на процессоры, но для каждого процессора будет лицензироваться определенное количество сконфигурированной памяти запущенных виртуальных машин (vRAM).

Если суммарная скинфигурированная память виртуальных машин будет превышать лицензированный пул vRAM - будет выдано предупреждение о необходимости устранения проблемы (то есть закупка дополнительных лицензий этого издания или апгрейд на более высокое издание, позволяющее иметь больше памяти для виртуальных машин на процессор хост-сервера). Для изданий vSphere 5 Essentials и Essentials Plus - такое событие будет не только ограничиваться предупреждением, но и невозможностью запуска виртуальных машин, выходящих за лимиты доступной vRAM.

Считается во времени это просто - в каждый момент времени за последние 12 месяцев величина скользящей средней к суммарной сконфигурированной vRAM виртуальных машин должна быть меньше или равна величине лицензированного пула vRAM (напоминаю, что пул vRAM считается отдельно в рамках каждого издания).

Чтобы помочь пользователям разобраться во всех этих тонкостях лицензирования, и выпущена утилита vSphere Licensing Advisor. Она подсчитывает количество сконфигурированной памяти ваших запущенных виртуальных машин и говорит вам о том, как это отразится на новой модели лицензирования, когда вы сделаете апгрейд на vSphere 5.

Выглядят результаты работы таким образом (кликабельно):

Учитывайте, что если у вас издание Advanced, то результаты будут отображены для издания Enterprise, поскольку издания Advanced уже больше не будет, а все пользователи этого издания получат Enterprise бесплатно (см. тут).

Вы можете поэкспериментировать с утилитой vSphere Licensing Advisor, выключая и включая ваши виртуальные машин и запуская ее снова для получения различных вариантов отчетов.

Скачать утилиту vSphere Licensing Advisor можно по этой ссылке.

P.S. Кстати, утилитой не поддерживаются окружения, где vCenter 4 управляет хостами ESX / ESXi 3.x. Ну и говорят, что там много багов пока в целом.

Это то, что придется большинству из вас. В продолжение нашей серии постов о миграции с VMware ESX на VMware ESXi, очень полезно вам будет посмотреть вот это видео:

Во время установки ESXi 5 установщик имеет несколько опций по сохранению предыдущих настроек VMware ESX и хранилищ VMFS.

Кстати, вот еще несколько мыслей об обновлении хостов с vSphere 4 на vSphere 5. И самая главная мысль - как выйдет ESXi 5 не надо рваться в первых рядах и обновлять хост-серверы, тома VMFS, Virtual Hardware и прочее в своей производственной среде. Подождите хотя бы 2-3 недели пока что напишут о багах и недоделках.

Вот как только вышла vSphere 4 мы поехали к заказчику (немаленькому) ставить ее на демо-стенде. Он выбирал между vSphere и Hyper-V. Мы сделали HA-кластер, начинаем показывать - бах, кластер не заводится после выключения хоста, машинки не стартуют. А оказалось - бага, которую почти сразу после нашего отъезда пофиксили. А заказчик он посмотрел, побурчал и поставил там Hyper-V. Так вот.

У Duncan'а Epping'а появилась познавательная статья о том, как перенести ваш текущий сервер VMware vCenter 4.0, 32-битная версия которого еще была в VMware vSphere 4.0 на платформу 64-бит (начиная с 4.1) с сохранением всей иерархии объектов, задач и данных о производительности.

Во-первых, если вы скачаете пакет VIM (VMware Infrastructure Management) с дистрибутивом vCenter 4.1, в ISO-архиве вы найдете папку datamigration с файлом datamigration.zip:

Теперь вам нужно сделать следующие шаги:

1. Поднять новый VMware vCenter 4.1 64-bit.

2. Открыть этот datamigration.zip и скопировать его содержимое в папку datamigration на вашем 32-битном сервере vCenter 4.0.

3. Остановить службы vCenter Service, Update Management Service и vCenter Web Service.

4. Запустить backup.bat.

5. После завершения процесса бэкапа скопируйте всю папку datamigration на целевой хост vCenter 4.1 64-bit (в то же место).

6. Запустите install.bat.

Далее:

• Подтвердите имя vCenter Server и нажмите Y
• Укажите путь к установочным файлам vCenter
• Укажите путь к установочным файлам VMware Update Manager (по умолчанию, тот же)
• Высветится окошко о том, что базы данных будут восстановлены на новом сервере
• Продится все это минут 15, после чего можно запускать vSphere Client и смотреть на новый сервер со всеми сохранившимися тасками, объектами, иерархией и т.п.

Ну и если чего не получается, не забываем про утилиту VMware InventorySnapshot с VMware Labs.

Мы уже вам надоели с необходимостью подготовки миграции вашей виртуальной инфраструктуры VMware vSphere с хостов ESX на ESXi (поскольку vSphere 5 будет только на базе ESXi), но, все-таки, пролжим деятельность в этом направлении.

Сначала предыдущие части:

• Новые технические документы VMware: продолжаем готовиться к миграции на ESXi
• План миграции с VMware ESX на ESXi и что делать после миграции (статья что-то сломалась, но мы ее починим)
• Различия ESX и ESXi - Scratch partition
• Как перейти с VMware ESX на VMware ESXi - часть 2
• Переход с VMware ESX на VMware ESXi - что делать?

Мы уже писали о средстве PXE Manager for vCenter, имеющемся на сайте проекта VMware Labs. Оно нужно для автоматизации развертывания хостов VMware ESXi (Stateless или Stateful) по PXE. Говорят, что утилита войдет в состав VMware vSphere 5. Работает оно только с хостами VMware ESXi, но в версии 4.1 Update 1 утилита получила функцию по миграции хостов ESX на ESXi:

Теперь в утилиту можно добавить хост ESX (предварительно вы уже должны создать образ ESXi):

А далее просто выбрать пункт "Convert this ESX Server to VMware ESXi Server". Дальнейший процесс миграции со скриптом постконфигурации описан в статье Andy Grant "PXE Manager Howto: Converting ESX hosts to ESXi".

Я уже, наверное, набил вам оскомину, но снова повторюсь - в версии VMware vSphere 5, которая выйдет в августе-сентябре (в подтверждение этому - посмотрите на книжку на Amazon, которая выходит 7 сентября), уже не будет платформы виртуализации VMware ESX. Останется только "тонкая" платформа VMware ESXi. Поэтому всем организациям необходимо планировать миграцию с ESX на ESXi. Об этом у нас есть серия постов:

• План миграции с VMware ESX на ESXi и что делать после миграции
• Различия ESX и ESXi - Scratch partition
• Как перейти с VMware ESX на VMware ESXi - часть 2
• Переход с VMware ESX на VMware ESXi - что делать?

Сегодня вам нужно положить в копилку еще пару документов. Первый - "Migrating to VMware ESXi":

Кроме того, появились чек-листы по миграции VMware ESX на ESXi, а также по апгрейду сервера VMware vCenter:

http://www.vmware.com/files/pdf/VMware-ESXi-41-Migration-Checklists.pdf

Также обратим внимание еще и на второй документ "VMware ESXi 4.1 Operations Guide":

В нем нам рассказывают о том, как нужно управлять виртуальной инфраструктурой VMware vSphere на базе VMware ESXi, и какие методики используются в сравнении с моделью управления на классическом ESX:

Для готовящихся к миграции и имеющих различные скрипты и агентов в сервисной консоли серверов ESX - читать обязательно.

Как вы уже знаете, VMware vSphere 5 будет уже только на базе гипервизора ESXi, а выпуск продукта ESX прекращается (версия 4.1 - последняя на базе этой платформы). Поэтому тем, кто еще не перешел на VMware ESXi нужно задумываться о миграции.

Мы уже писали на тему того, как перейти с ESX на ESXi (тут, тут и тут), а сегодня расскажем в общих чертах о плане миграции таких хост-серверов и о том, что делать после установки нового ESXi (пост-миграционные процедуры).

Как мы уже неоднократно писали, следующая версия платформы виртуализации VMware vSphere 5, которая выйдет в этом году, будет поставляться только на базе гипервизора VMware ESXi. Это означает, что всем пользователям VMware vSphere, которые работают с VMware ESX (а таких большинство), нужно уже сейчас задуматься о переходе на продукт ESXi.

Когда вышла VMware vSphere 4.1 в Release Notes мы могли прочитать подтверждение данного факта:

VMware vSphere 4.1 and its subsequent update and patch releases are the last releases to include both ESX and ESXi hypervisor architectures. Future major releases of VMware vSphere will include only the VMware ESXi architecture.

Поддержка же VMware ESX будет осуществляться в соответствии с политиками "VMware Enterprise Infrastructure Support".

Сегодня мы поговорим о том, что нужно учитывать при неизбежной миграции на VMware ESXi c ESX, и почему можно сказать, что этот переход не будет особо болезненным. Для начала нужно посетить ресурс по переходу на ESXi на сайте VMware. Там есть много интересного, а в частности ESXi 4.1 migration guide, в котором описаны тонкости процесса миграции.

Если вы не хотите читать этот огромный 13-страничный гайд, то есть небольшая выжимка в виде презентации "Transitioning to the ESXi Hypervisor", где можно найти много полезной информации.

В частности, у каждого аспекта управления в VMware ESX есть свой аналог в VMware ESXi, совокупность которых справляется со всеми задачами, присутствующими в виртуальной инфраструктуре vSphere:

Кстати интересная фраза (август, 2010): "VMware users should put a plan in place to migrate to ESXi during the next 12 to 18 months".

Теперь вместо агентов в гостевой ОС (ESX), у нас есть партнерские модули Common Information Model (CIM) в ESXi:

В версии VMware ESX / ESXi 4.1 компания VMware свела различия в функциональности двух платформ к минимуму (красным выделено появившееся в 4.1):

Для диагностики и решения проблем у нас есть куча локальных и удаленных интерфейсов в ESXi. Tech Support Mode также поддерживается локально и по SSH, что делает настройку ESXi простым делом:

Через клиента vSphere Client или браузер мы проводим стандартные операции, в DCUI лезем, если что-то зависло, а TSM используем для глубокого копания.

К файлам настройки на ESXi мы можем ходить через браузер:

И к лог-файлам тоже:

Ну, то есть в ESXi есть то же, что и в ESX - поэтому переходить можно смело:

По поводу того, как прейти на VMware ESXi с ESX. Да просто возьмите и переустановите, если нужно - ничего у вас не сломается. Только помните, что смешанные кластеры раньше не поддерживались, а как теперь - не знаю. Дальше учитесь использовать VMware Management Assistant (vMA), vCLI и PowerCLI - это не так сложно.

И, напоследок, для всех тех, кто хотел узнать, что за продукт такой vSphere Hypervizor:

VMware vSphere Hypervisor is the new name for what was formerly known as VMware ESXi Single Server or free ESXi (often abbreviated to simply “VMware ESXi”)

Пакет продуктов VMware vSphere 4.1 вышел уже две недели назад, особенных ошибок в новой сборке выявлено не было, а значит настало время обновлять свои хосты VMware ESX 4.0 Update 1 или Update 2 на VMware ESX 4.1.

Прежде всего, вам надо пойти по этой ссылке на сайт VMware и скачать два пакета для проведения обновления (у вас должен быть действующий контракт на подписку SnS):

• pre-upgrade-from-ESX4.0-to-4.1.0-0.0.260247-release.zip
• upgrade-from-ESX4.0-to-4.1.0-0.0.260247-release.zip

Далее нужно скопировать эти файлы в сервисную консоль сервера VMware ESX, например, с помощью бесплатной утилиты Veeam FastSCP. После этого в Service Console VMware ESX 4.0 выполняем следующие действия:

1. Переводим хост в Maintenance Mode. Это можно сделать либо из vSphere Client, либо командой:

# vimsh -n -e /hostsvc/maintenance_mode_enter

2. Выполняем команду в директории с файлами обновления:

# esxupdate update --bundle=pre-upgrade-from-ESX4.0-to-4.1.0-0.0.260247-release.zip

3. Выполняем команду:

# esxupdate update --bundle=upgrade-from-ESX4.0-to-4.1.0-0.0.260247-release.zip

После успешного апгрейда на VMware ESX 4.1 нам напишут в консоли:

The update completed successfully, but the system needs to be rebooted for the  changes to be effective.

4. Соответственно, выполняем:

# reboot

5. Выходим из Maintenance Mode после перезагрузки ESX:

# vimsh -n -e /hostsvc/maintenance_mode_exit

Заждались? Но, не волнуйтесь, он уже здесь - пятый выпуск обзора бесплатных программ и утилит для виртуальной инфраструктуры VMware vSphere / ESX / ESXi. Сегодня мы рассмотрим все самые интересные бесплатные средства администрирования и управления серверами ESX и ESXi, а также приведем ссылки на все заметки VM Guru, опубликованные ранее по этой теме.

Компания Citrix продолжает развитие своих продуктов для виртуализации инфраструктуры предприятий на всех уровнях ИТ. Citrix XenApp, средство для виртуализации и доставки приложений, ранее был флагманским продуктом компании, теперь же ему на смену пришел Citrix XenDesktop как более комплексное и законченное решение для ИТ-инфраструктуры. Сам XenApp стал частью решения по виртуализации корпоративных ПК Citrix XenDesktop, но продолжает свое развитие как независимый продукт. На днях вышла предварительная версия Citrix XenApp 6 Tech Preview под кодовым названием Parra.

Андрей Вахитов (vmind.ru) в своем блоге разместил просочившуюся информацию о новой функциональности готовящегося к выпуску релиза платформы виртуализации VMware vSphere 4.1, включая ESX 4.1 и vCenter 4.1.

Приблизительный список основных новых возможностей VMware vSphere 4.1:

• Поддержка развертывания тонкого гипервизора VMware ESXi по PXE.
• Контроль обмена трафиком с системой хранения Storage I/O Control в стиле QoS.
• Network I/O Traffic Management - более гибкое регулирование полосы пропускания сетевого взаимодействия виртуальных машин (в том числе сети VMotion, Fault Tolerance).
• VMware HA Healthcheck Status - автоматическая проверка работоспособности VMware HA, при этом в случае отклонения настроек кластера от требуемых выдается Alarm в VMware vCenter.
• Fault Tolerance (FT) Enhancements - теперь FT полностью интегрирован с VMware DRS, работает в кластерах EVC, а первичные и вторичные виртуальные машины корректно балансируются DRS. Кроме того, VMware FT может теперь работать без VMware HA.
• vCenter Converter Hyper-V Import - можно импортировать виртуальную машину на ESX с сервера Hyper-V
• DRS Virtual Machine Host Affinity Rules - возможность запрещать некоторые хосты к размещению на них ВМ. Пригодится для соблюдения лицензионной политики.
• Memory Compression - новый уровень абстракции оперативной памяти ВМ. Быстрее чем засвопированная на диск память, но медленнее, чем физическая.
• vMotion Enhancements - теперь VMotion работает быстрее (до 8 раз), и увеличено число одновременных миграций ВМ на хосте (с 4 до 8).
• 8GB Fibre Channel Support
• ESXi Active Directory Integration - теперь ESXi можно загнать в AD.
• Configuring USB Device Passthrough from an ESX/ESXi Host to a Virtual Machine - поддержка USB-устройств на хосте ESX / ESXi, пробрасываемых к виртуальной машине.
• User-configurable Number of Virtual CPUs per Virtual Socket - по-сути, многоядерные (не путать с многопроцессорными) виртуальные машины. Несколько виртуальных ядер в одном виртуальном vCPU.